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Description 

.Met hod for the automatic retrieval of encrineerincf_^ data 
from installations 



The invention relates to a method for the automatic 
retrieval of engineering data from installations. 

An automation system of this type is used in particular 
10 in the area of automation technology. An automation 
O system of this type generally comprises a multiplicity 

yj of individual automation objects, which are frequently 

highly dependent on the engineering system respectively 
used . 



y*i is 



At present there are two basic methods in use. In the 
£3 first method, the retrieval of the engineering data 

from the installation is ruled out. Changes to the 
installation are possible only via the engineering 

C3 20 tool. Consequently, the data in the engineering system 

"i i 

always reflect the current state and there is no need 
for information to be reproduced from the installation. 
This solution has the following disadvantages: 

Strong link between runtime and engineering: The 

2 5 engineering system must be supplied along with the 
installation and also be additionally paid for by the 
customer . 

Changes in the installation cannot be reproduced: If 

there are changes in the installation, for example as 

3 0 a result of a device being exchanged, these changes 
cannot be automatically reproduced in the engineering 
system. 

High organizational expenditure: To keep the 
engineering data up to date, organizational 
3 5 precautions have to be taken to ensure the way in 

which changes in the installation are introduced into 
the engineering system. 
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The second approach is based on a disassembly of the 
runtime code. In this case, the executable code of the 
runtime objects is analyzed and translated into the 



following disadvantages : 

£, Elaborate method: The analysis of the runtime code is 
complex and susceptible to errors. 

£, Implementation-dependent: The implementation of the 
translation back is strongly dependent on how the 
translation process is carried out. Changes to the 
translation process and in particular the code 
created necessitate adaptation of the implementation 
of the translating-back process. 

ES information can no longer be produced with 
certainty: Since the runtime code is at a 
semantically lower level than the actual engineering 
information, it cannot be ensured that the 
engineering information can be exactly reconstructed. 

In the specialist article Elmqvist, H. : "A Uniform 
Architecture for Distributed Automation 11 , Advances in 
Instrumentation and Control, vol. 46, part 2, 19 91, 
pages 1599-1608, XP000347589 Research Triangle Park, 
NC, US, a description is given of an automation system 
whose objects are programmed in an object- and data- 
flow-oriented programming language. It uses a graphic 
programming environment and offers means for the 
creation of dynamically updated process images. The 
programming language allows an automatic communication 
between distributed objects. 

The problem underlying the invention is that of 
allowing the information contained in an installation 



engineering counterparts . 



This 



solution 



has 



the 
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to be automatically reproduced in an engineering system 
and used again there, for example to plan changes in 
the installation. 

This object is achieved by a method and by a system 
with the features specified in claims 1 and 8, 
respectively. 

In this case, the engineering and runtime objects are 
described by a uniform object model. As a result, the 
correspondence between engineering objects and runtime 
objects can be determined at the object level and no 
information is lost as a result of the mapping. In 
addition, a direct communication between engineering 
and runtime objects can take place, which can be 
utilized when the method is carried out. 

The relationship between an engineering object and its 
runtime counterpart is described in figure 1. The 
engineering object ESO has a direct reference, RTO ref, 
to its 
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runtime counterpart RTO. This is possible since the 
runtime objects are available (or become available) at 
the time of engineering. The runtime object RTO has no 
direct reference to the associated engineering object. 
5 This is necessary to make it possible for the 
engineering system and runtime system to be separated. 
Instead of this, the object RTO contains an identifying 
designation, ESO type ID, referring to the type of 
engineering object, ESO type. Consequently, required 

jjgj 10 instances of the ESO type can then be created by the 

£ RTO. 

JS With respect to a runtime object RTO, the method for 

*B the restoration of engineering information proceeds as 

m 

15 follows: 

Q 1. If a runtime" obj ect receives the order to retrieve 

fT' its engineering information, it firstly addresses 

QQ the type of its engineering object with the order 

|3 to create a new instance of an engineering object. 

fti 

20 2. In the newly created instance, the runtime object 
enters a reference to itself and orders the new 
engineering object to read out its data (that of 
the runtime object) . 
3. The new engineering object then reads out the 

2 5 information from the runtime object and enters the 

corresponding engineering information in itself. 

The invention is described and explained in more detail 
below on the basis of the exemplary embodiments 

3 0 represented in the figures, in which: 

figure 1 shows an overview to identify the 

relationships between engineering objects and 

runtime objects, 
35 figure 2 shows a view of an object of an installation 

by way of example, 
figure 3 shows an illustration of the creation of 

device representatives in the engineering, 
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figure 4 shows a representation of the creation of the 
automation objects in the device 

representatives by way of example and 

figure 5 shows a layout of the existing communication 
relationships in the engineering. 



The method for the retrieval of engineering information 
from the installation proceeds in three steps: 
Restoration of the device representatives 
Restoration of the representatives of the automation 
objects in the engineering 

Restoration of the communication relationships 
between the representatives of the automation objects 
The method is described below for the complete 
retrieval of the engineering information. However, it 
can equally be used for updating already existing 
engineering information, i.e. as a delta method. 
Hereafter, the overall method is referred to as upload. 
In figure 2, the objects involved are listed by way of 
example. Two automation objects run on each of the two 
devices RG1 and RG2 . The automation objects RAOl and 
RA02 run on RG1 , RA03 and RA04 run on RG2 . 
Communication connections are symbolized by lines. 
Thus, altogether two device-internal and two device- 
interlinking communication relationships exist. 

2. Restoration of the device representatives 

The beginning of the upload is initiated from a 
software system. This may be an engineering system or 
3 0 any other desired system which requires engineering 
information. One example of this is a system for 
parameterizing the installation. For the sake of 
simplicity, hereafter reference is always made to an 
engineering system. In the first step, all the devices 
3 5 are requested to create their representation in the 
engineering. For this purpose, each device returns an 
identifier of the type of its engineering counterpart. 
The engineering system then creates the corresponding 
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objects and enters the reference to the actual device 
in each device representative. By means of the 

reference, each device representative then reads out 
the relevant data of "its" device. 

Figure 3 illustrates what has just been described. The 
devices of the installation, here RG1 and RG2 , receive 
the request to upload through the engineering system. 
They then in each case return the identifiers of the 
types of the engineering representatives. The 
engineering system creates the instances Gl and G2 for 
the corresponding types. These then read out the 
relevant engineering information from the devices RG1 
and RG2 . 

2. Restoration of the automation objects in the 
engineering 

In the second step, the representatives of the 
automation objects are created in the engineering. Via 
the device assigned to it 7 each device representative 
requests the automation objects of its device to create 
its counterparts in the engineering. For this purpose, 
each automation object returns the identifier of the 
type of its engineering representative. In the 

engineering system, the corresponding objects are then 
again created and provided with a reference to their 
partner in the runtime environment. After that, each 
automation object in the engineering inquires the 
relevant data of its partner. 

The result of this operation can be seen in figure 4. 
The representative Gl inquires from the device RG1 the 
automation objects RAOl and RA02 . These are then 
requested to upload by Gl and return the identifiers of 
the types of AOl and A02 . By means of this 

information, the instances AOl and A02 are created in 
the engineering. These then receive a reference to 
their runtime counterparts RAOl and RA02 are finally 
assigned to the device representative Gl . As a result, 
the information on the device assignment of the 
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automation objects is available again. Subsequently, 
A01 and A02 read out the information relevant for 
engineering from RAOl and RA02 . 
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3. Restoration of the communication relationships 
between the automation objects in the engineering 

In the final step, the communication relationships 
between the automation objects are restored. For this 
purpose, each device representative asks the device 
assigned to it for its communication relationships. 
The device then returns a list with both the device- 
internal and device- interlinking communication 
relationships. An entry of this list comprises the 
source and drain of the communication relationship. 
The source and drain are in each case described by a 3- 
tuple from the identifier of the physical device, the 
identifier of the automation object and the identifier 
of the input or output . 

In the engineering system, the entries of the list are 
converted into references to the inputs and outputs of 
the representatives of the automation objects. For 
this purpose, the information from the already created 
objects (the references of the engineering 
representatives to their runtime counterparts) is used. 
Subsequently, the connection in the engineering system 
is then set up. 

An efficient way of carrying out the step will ensure 
that the list with communication connections created by 
each device only contains those in which the device 
appears in the identifier of the source (alternatively 
of the drain) . Furthermore, an effective method will 
buffer-store the relationships between engineering 
representatives and runtime counterparts set up in 
steps 1 and 2, in order in this way to minimize the 
searching effort in step 3 . 

Figure 5 then shows the result of the last step. Gl 
has inquired the communication relationships from RG1 . 
In response, the relationships between RAOl and RA02 , 
RAOl and RAQ3 and between RAQ2 and RAQ4 were returned. 
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The connections are then converted in the engineering, 
for example the connection 
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between RA01 and RA03 is converted to the connection 
between A01 and A03 . 

Both the obj ects of the engineering system and of the 
runtime system are based on the same, executable object 
model. The use of the same model makes possible a 
direct interaction at model level (data exchange and 
communication) between the engineering obj ects and 
runtime obj ects . Furthermore , a unique mapping, which 
is independent of the implementation of the objects, is 
defined by the defined assignment between the 
engineering and runtime objects. 

This gives rise to the following advantages for the 
method : 

Separation of engineering and runtime possibles Changes 
do not necessarily have to be carried out with the 
engineering tool . If need be, the changes can be 
introduced into the engineering system at any time. 
Simple method; By determining the method at the level 
of explicit models , the method can be described in 
general terms and so becomes more reliable . 
Simple and complete mappings There is a . defined 
relationship between the runtime and engineering 
objects, making complete restoration of the engineering 
information possible. 

Stable with respect to changes in implementations 

Implementation of the runtime and engineering obj ects 
can be changed over without having any influence on the 
mapping and consequently on the way in which the method 
is carried out. 

Non- tool-specif ic s The upload mechanism, can also be 
used by other tools and not just by the engineering 
system. 



